This section provides background information related to the present disclosure and is not necessarily prior art.
An application (referred to interchangeably in this disclosure as an “app”), such as a mobile app, may contain multiple deep states. For example, in an app that ranks the quality of restaurants based on social media opinion data, the detail page for each restaurant would be considered a deep state. Deep states are reachable from within the app through a sequence of user actions that can involve navigating through multiple menu screens and selections of user interface elements. Each of these menu screens and user interface elements can be mediated by a unique view controller associated with that displayed screen.
Usually, these deep states are accessible only from within the app itself. Web search engines operating outside the app, for example, cannot reach the deep states within the app. This requires considerable interaction by the user. When a user conducts a conventional web search for restaurants and wants to explore one of the returned choices in a specialized restaurant ranking app, the user would have to manually copy and paste the name of the selected search result into the search field of the restaurant ranking App and command the restaurant ranking app to access its internal deep state corresponding to the selected restaurant.
If deep states of apps could be exposed to external apps and computer processes, the user could enjoy the augmented functionality, for example, of being able to begin a search for a suitable restaurant using an Internet-based search server and then to have the results of that search automatically displayed in the appropriate deep linked page of a specialized restaurant ranking app.
However, implementing such functionality requires developer effort and requires deep linking expertise that the developer may not possess. When app development is limited by time or budget, deep link functionality for some or even all of the states of an app may not be a high enough priority to get implemented.
In FIG. 1A, an example relationship between view controllers and views is shown for a hypothetical app 100. The app 100 includes view controllers 104-1, 104-2, and 104-3, which respectively control View A 108-1, View B 108-2, and View C 108-3. The view controllers 104-1, 104-2, and 104-3 (collectively, view controllers 104) are linked so that user action causes a transition from one of the view controllers 104 to another of the view controllers 104.
In the example of FIG. 1A, user action at A invokes the view controller 104-1, which instantiates View A 108-1. User action at B transitions to the view controller 104-2, which instantiates View B 108-2. User action at C transitions to the view controller 104-3, which instantiates View C 108-3. User action at D transitions from the view controller 104-3 back to the view controller 104-2, which results in View B 108-2 being instantiated. From the standpoint of View C 108-3, View A 108-1 and View B 108-2 are intermediate views through which user action transitions on the way to View C 108-3.
The app 100 may not include a mechanism for any internal request or external request (such as from a browser or a search function of an operating system) to directly reach View C 108-3. In other words, deep links are not available to View B 108-2 or View C 108-3. Further, even if the developer has implemented internal deep links to allow the app 100 to directly access View B 108-2 or View C 108-3, the app 100 may not have exposed this deep linking capability so that deep link instructions can be submitted to the app 100 from external sources.
In FIG. 1B, another example visual representation of the relationship between views and view controllers is shown. A hypothetical app 150 includes view controller 154-1 and view controller 154-2 (collectively, view controllers 154). As seen in FIG. 1B, a single view controller (such as the view controller 154-1) may be responsible for multiple views.
View A 158-1 and View B 158-2 are both controlled by the view controller 154-1. Meanwhile, View C 158-3 is controlled by the view controller 154-2. Collectively, View A 158-1, View B 158-2, and View C 158-3 are referred to as “views 158.” View A 158-1 may be the default view displayed when the app 150 is started. User action at B may transition from View A 158-1 to View B 158-2, a transition that is mediated by the view controller 154-1. User action at C may transition from View B 158-2 to View C 158-3, which is accompanied by a corresponding handoff from the view controller 154-1 to the view controller 154-2. User action at D transitions from View C 158-3 back to View B 158-2.
View A 158-1 and View B 158-2 may have some similarities and may, therefore, be controlled by the same view controller 154-1. For example, View A 158-1 may be responsible for supporting basic restaurant information, while View B 158-2 may be responsible for displaying more detailed restaurant information. In another example, where the app 150 is a general travel app instead of a restaurant-specific app, View A 158-1 may correspond to restaurant information while View B 158-2 may correspond to event information.
In some app implementations, a single view controller may control all of the views. In other implementations, each view may be controlled by an independent view controller. A view may correspond to a template, or layout, which can be populated with different entity information. The view controllers 154 and the views 158 may be developed according to the model-view-controller (MVC) software architecture pattern.
For example, View B 158-2 may display restaurant information from a data model and may therefore include elements for displaying the name of the restaurant, representative pictures of the restaurant, reviews of the restaurant, and user interface elements for performing actions, such as booking a table at the restaurant, writing a review, etc. The view controller 154-1 may instantiate View B 158-2 with respect to a specific restaurant, at which point the metadata for that restaurant is used to populate View B 158-2 in order to render View B 158-2 for display to the user.